一图看懂Django和DRF

Django和DRF用了很久了，一直没有认真的总结一下，没什么总结比一张框图更暴力了。最近根据使用经验画了几张图，下面这两张图分别是Django的框图和Django REST Framwork的框图。

Django在Python的web框架中是出了名的重，而DRF即Django REST Framwork更重，这使得广大小伙伴在做完了Django的Tutorial和DRF的Tutorial之后仍云里雾里。要知道，相比于flask只需要一个装饰器和一个函数就可以把服务跑起来，这个学习路线确实是有点繁琐。而且在花时间跑完这些tutorial之后，却陷入了一个更大的疑惑就是，搞这些有的没的是为了啥？

简洁是一种力量，我试着用最简短的语言描述一下为什么有Django以及为什么有了Django还有个DRF。

最少的语言描述Django？

将数据库的东西通过ORM的映射取出来，通过view文件，按照template文件排出的模板渲染成HTML。当用户请求相应的url时，返回相应的结果。

最少语言描述DRF？

将数据库的东西通过ORM的映射取出来，通过view和serializers文件绑定REST接口，当前端请求时，返回序列化好的json。

最少语言描述DRF在Django的基础上做了什么？

DRF是Django的超集，去掉了模板的部分，提供了一个REST的接口，同时也提供了满足该接口的代码工作流。同时，在REST的规范下，升级了权限和分页等功能，增加了限流和过滤搜索等功能。

Django和DRF的tutorial分别讲了什么？

Django的tutorial讲的是Django的ORM、template、url、admin以及Django怎么run起来等基础知识。

而DRF的tutorial讲的是serializers怎么写，view怎么写，在drf中view这一层既可以一个个get、post、从头开始写起，也可以采用抽象程度比较高的viewset去按配置生成。另外还讲了一些drf升级和新增的功能。

Django+DRF将后端变成一种声明式的工作流，只要按照models->serializers->views->urls的模式去一个个py文件去配置，即可生成一个很全面的通用的后端。当然，如果需求不那么通用，这种设计就变成了一个累赘。

事实上，过重的设计降低了灵活性，报错基本得去翻源码实现，然后再吐槽一遍源码实现，这也是有得必有失。当然，现在Django和DRF一直在优化middeware的设计，也有api_view这种类似flask的装饰器的实现方式，也是在灵活性方面的一种权衡，不过对于初学者来说，仍然是个不大不小的坎。

前后端分离的部署也可以用一张图来描述如下，这么一看是不是很清晰了呢！

图片传上知乎后就不清晰了，不知道怎么解决。另外由于本人能力有限，如果图画的有问题请私信我修改，请各位大佬轻拍。